LSPS5 implementation #3662

martinsaposnic · 2025-03-11T20:12:16Z

A complete implementation for LSPS5 (spec defined here lightning/blips#55)

Reviewing commit by commit is recommended (~40% of the added lines are tests)

Notes:

Persistence of the state will come on a future PR
~~- Will rebase from lightning-liquidity: Introduce EventQueue notifier and wake BP for message processing #3509 once that PR is merged~~ DONE

ldk-reviews-bot · 2025-03-11T20:12:19Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

martinsaposnic · 2025-03-11T20:16:28Z

This is a huge PR, but it wasn’t obvious to me how to split it in a way that would still make sense (I did split it into small commits to make it easier to review.). I’m open to suggestions if you have ideas on how this could be structured differently.

codecov · 2025-03-11T20:21:35Z

Codecov Report

Attention: Patch coverage is 86.38596% with 194 lines in your changes missing coverage. Please review.

Project coverage is 88.84%. Comparing base (2f9898c) to head (2586494).

Files with missing lines	Patch %	Lines
lightning-liquidity/src/lsps5/msgs.rs	76.84%	81 Missing and 16 partials ⚠️
lightning-liquidity/src/lsps5/client.rs	90.59%	30 Missing and 3 partials ⚠️
lightning-liquidity/src/lsps5/service.rs	91.16%	20 Missing and 5 partials ⚠️
lightning-liquidity/src/lsps0/ser.rs	79.16%	3 Missing and 17 partials ⚠️
lightning-liquidity/src/lsps5/url_utils.rs	94.87%	1 Missing and 5 partials ⚠️
lightning-liquidity/src/manager.rs	93.84%	2 Missing and 2 partials ⚠️
lightning-liquidity/src/lsps5/validator.rs	95.83%	0 Missing and 3 partials ⚠️
lightning/src/util/test_utils.rs	50.00%	3 Missing ⚠️
lightning/src/ln/blinded_payment_tests.rs	0.00%	2 Missing ⚠️
lightning-liquidity/src/lsps0/msgs.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3662      +/-   ##
==========================================
- Coverage   89.05%   88.84%   -0.21%     
==========================================
  Files         167      171       +4     
  Lines      121800   123097    +1297     
  Branches   121800   123097    +1297     
==========================================
+ Hits       108464   109364     +900     
- Misses      10928    11351     +423     
+ Partials     2408     2382      -26

Flag	Coverage Δ
fuzz	`?`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

tnull

Wow, thank you for looking into this! I did a first pass, and it looks pretty amazing already!

Before going too much into further details, here are a few general comments upfront:

I'm generally no fan of introducing additional dependencies here, an in particular not reqwest and tokio. I think following the pattern so far BroadcastNotifications could be a request that the user handles with any HTTP client they want and then could call back into LSPS5ServiceHandler. Alternatively, we could also use a trait similar to the current HTTPClient, but I don't think we want to keep the default implementation. Note that the blocking reqwest variant wraps a tokio runtime internally, and therefore should never (1, 2, ...) be used together. I guess technically we could consider a default async version of the trait that uses async reqwest, but I would prefer to simply have well-documented trait on our end that the user can implement however they choose to. Also note that stacking tokio runtimes is heavily discouraged in general, so assuming our users would themselves use a tokio runtime, we shouldn't wrap one in LSPS5ServiceHandler.
Note that lightning-liquidity is optionally no-std compliant, so please don't rely on std wherever possible, often it's just a matter of using core instead and importing the respective types from crate::prelude. If you really find yourselves needing to use std, make sure it's feature gated behind feature = "std" and we provide an alternative for users that don't support it.
Minor: Regarding formatting we're using tabs, not spaces. Feel free to run ./contrib/run-rustfmt.sh after each commit to run our formatting scripts.
This PR in its current scope is great, just want to note that eventually we need to add persistence for the state. As we haven't fully fleshed out the persistence strategy for lightning-liquidity in general yet, it's actually preferred to defer this to a follow-up, but just wanted to mention it. Also note that some changes to MessageQueue/EventQueue will happen in #3509, but will ping you to rebase once that has been merged. (just sidenotes here).

I hope these initial points make sense, let me know if you have any questions, or once you made corresponding changes and think this is ready for the next round of review!

ldk-reviews-bot · 2025-03-13T12:45:04Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

tnull · 2025-03-13T12:48:30Z

This is a huge PR, but it wasn’t obvious to me how to split it in a way that would still make sense (I did split it into small commits to make it easier to review.). I’m open to suggestions if you have ideas on how this could be structured differently.

Thanks for asking! I'm totally fine to keep this (with its current scope) in a single PR, as long as we keep the commit history pretty clean to allow continuing review to happen commit-by-commit. To this end, please make sure add any fixup commits clearly marked (e.g. via a f or fixup prefix in the commit message header) directly under the commit they belong to, so they can cleanly be squashed into the respective feature commits in-between review rounds.

tnull · 2025-03-13T12:54:53Z

Btw, I'm not sure if you're familiar with the previous attempt of implementing LSPS5: #3499

Given this is a clean slate, not sure how much there is to learn, but still might be worth a look. Also not sure if @johncantrell97 would be interested in reviewing this PR, too, as he's familiar with the codebase and LSPS5.

martinsaposnic · 2025-03-14T17:11:07Z

@tnull, ready for the next review round!

Removed reqwest and tokio.
HttpClient is now a generic trait, allowing users to pass any implementation.
Removed std.
Small refactor on client and service to be able to delete some silly / unnecessary code.
Ran formatting on every commit.
All new changes are in commits prefixed with fixup:.

CI is failing because of the usage of the url crate (which I guess does not support rust 1.63?), which I need for validating the webhook URL. A new commit will come addressing that shortly

ldk-reviews-bot · 2025-03-17T00:00:52Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-03-17T00:00:54Z

🔔 1st Reminder

Hey @tnull @valentinewallace! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

martinsaposnic · 2025-07-20T13:34:51Z

Although, now that #3927 landed, this PR unfortunately needs a rebase and the tests have to to be re-written based on the test_utils (either way, but I now went with landing #3927 as it was ready, hope that's okay).

Rebase done and conflicts resolved.

Also, the bug discussed on friday (notification signing flow bug) is fixed now. As discussed, a sign_message method is added to NodeSigner, and a NodeSigner is added to LiquidityManager and to LSPS5/service so it can sign notifications correctly. Relevant commits: 0e8a683 and 7ff724d

I agree we can avoid the timestamp validation, and probably can drop TimeProvider from LSPS5ClientHandler and LSPS5Validator. I'm actually also tempted to drop the spec protocol extensibility (i.e., to use anything else but HTTPS) and the x-lsps5-timestamp from the spec.

Happy to have these changes happen here or in a follow-up.

This sounds good to me, and I have the changes ready (in a different branch), which I prefer to include in a follow up once this PR is merged, if that's ok to you @tnull @TheBlueMatt

tnull

Fixups look mostly good to me. I did another pass and commented what stood out to me. For me only the comments regarding the new NodeSigner::sign_message interface and revisiting the commit messages are blocking, everything else could happily be done in follow ups after we land this.

tnull · 2025-07-21T08:26:19Z

lightning-liquidity/src/manager.rs

 					config.clone(),
-					time_provider,
-				);
+					time_provider.clone(),


Why do we suddenly need to clone here?

tnull · 2025-07-21T08:41:12Z

lightning/src/sign/mod.rs

@@ -930,6 +930,9 @@ pub trait NodeSigner {
 	/// message to be broadcast, as otherwise it may prevent one from receiving funds over the
 	/// corresponding channel.
 	fn sign_gossip_message(&self, msg: UnsignedGossipMessage) -> Result<Signature, ()>;
+
+	/// Sign an arbitrary message with the node's secret key.
+	fn sign_message(&self, msg: &[u8]) -> Result<String, ()>;


I think we should be able to make this infallible? Should we include the docs from sign here, too?

Also, I wonder if we also mention that this might panic, similar to what we do above in sign_gossip_message, although it seems we could do a better job describing when this would panic.

I will make this only return String.

I thought it made sense to keep the style of the other sign methods, but message_signing::sign does not panic, so I don't see the point of returning a Result instead of a String

fixup commit a1180a6, also improving the docs on the sign_message method @tnull

Thanks, the fixup looks good, but I have to eat my words as it turns out we made the signing methods fallible to account for the case of a remote signer. So, we need to make sign_message fallible afterall, excuse the churn :/

No problem at all. I dropped the commit that changed the sign_message method return type and replaced it with this one 75ece86 that only changes the documentation of sign_message

tnull · 2025-07-21T08:50:33Z

lightning-liquidity/src/lsps5/service.rs

nit: Commit message of this commit is outdated by now (e.g., we don't have an HttpClient trait anymore). Might be good to revisit all of them once more to check they reflect the current state before we land this PR?

tnull · 2025-07-21T08:52:23Z

lightning-liquidity/src/lsps5/service.rs

+///
+/// This trait is used to provide the current time for LSPS5 service operations
+/// and to convert between timestamps and durations.
+pub trait TimeProvider {


Might be worth moving this to some crate::utils::time or similar path, if we'll end up keeping it at all. (in a follow-up)

tnull · 2025-07-21T09:02:15Z

lightning-liquidity/src/lsps5/service.rs

+		self.broadcast_notification(client_id, notification)
+	}
+
+	fn broadcast_notification(


nit: This is named a bit misleading, as we just send the notification, we don't 'broadcast' (i.e., disseminate to multiple peers/endpoints). (could be renamed in a follow-up)

tnull · 2025-07-21T09:06:20Z

lightning-liquidity/src/lsps5/service.rs

+			if webhook
+				.last_notification_sent
+				.get(&notification.method)
+				.map(|last_sent| now.clone().abs_diff(&last_sent))


I think we should just make LSPSDateTime copy rather than explictly cloneing here and below, etc.

(in a follow-up)

tnull · 2025-07-21T09:10:30Z

lightning-liquidity/src/lsps0/ser.rs

@@ -214,6 +239,16 @@ impl LSPSDateTime {
 			self.0.timestamp().try_into().expect("expiration to be ahead of unix epoch");
 		now_seconds_since_epoch > datetime_seconds_since_epoch
 	}
+
+	/// Returns the time in seconds since the unix epoch.


These docs are wrong. I also wonder if this should just be fn duration_since(&self, other: &Self) -> Duration rather than returning a u64. (could both be done in a follow-up)

tnull · 2025-07-21T09:23:03Z

lightning-liquidity/src/lsps5/client.rs

+#[derive(Debug, Clone)]
+/// Configuration for the LSPS5 client
+pub struct LSPS5ClientConfig {
+	/// Maximum age in seconds for cached responses (default: 3600 - 1 hour).


nit: Rather than replicating the default values in the doc, let's just link to DEFAULT_RESPONSE_MAX_AGE_SECS, which avoids them getting stale (in a follow-up).

tnull · 2025-07-21T09:27:02Z

lightning-liquidity/src/lsps5/client.rs

+	{
+		let mut outer_state_lock = self.per_peer_state.write().unwrap();
+		let inner_state_lock = outer_state_lock.entry(counterparty_node_id).or_insert(Mutex::new(
+			PeerState::new(self.config.response_max_age_secs, self.time_provider.clone()),


We'll cleanup the individual response entries, but would we ever clean up the overall PeerState once it's empty?

This will be used to allow disabling time-dependent functionality. 'time' is included in the features default.

Introduce new_from_duration_since_epoch constructor from Duration. Also add abs_diff function to use on client / service. Also do feature='time' instead of feature='std' on time related functionality

martinsaposnic · 2025-07-21T14:06:13Z

The requested changes on NodeSigner::sign_message are pushed 51a0655, and all the commit messages were reviewed and rewritten accordingly.

Let me know if they look ok so I can squash them @tnull

Changes coming in a follow up (I may create an issue for this?):

avoid timestamp validation on validator
drop TimeProvider from LSPS5ClientHandler and LSPS5Validator
check unnecesary time_provider.clone() in manager LSPS5 implementation #3662 (comment)
Move time_provider trait into crate::utils::time or similar LSPS5 implementation #3662 (comment)
rename broadcast_notification in service (LSPS5 implementation #3662 (comment))
copy LSPSDateTime instead of cloning LSPS5 implementation #3662 (comment)
docs wrong and return Duration instead of u64 on abs_diff LSPS5 implementation #3662 (comment)
do not duplicate DEFAULT_RESPONSE_MAX_AGE_SECS LSPS5 implementation #3662 (comment)
clean up the overall PeerState once it's empty LSPS5 implementation #3662 (comment)

tnull · 2025-07-21T14:46:11Z

The requested changes on NodeSigner::sign_message are pushed 51a0655, and all the commit messages were reviewed and rewritten accordingly.

Let me know if they look ok so I can squash them @tnull

Changes coming in a follow up (I may create an issue for this?):

* [ ]  avoid timestamp validation on validator

* [ ]  drop TimeProvider from LSPS5ClientHandler and LSPS5Validator

* [ ]  check unnecesary time_provider.clone() in manager [LSPS5 implementation #3662 (comment)](https://github.com/lightningdevkit/rust-lightning/pull/3662#discussion_r2218510341)

* [ ]  Move time_provider trait into crate::utils::time or similar [LSPS5 implementation #3662 (comment)](https://github.com/lightningdevkit/rust-lightning/pull/3662#discussion_r2218559905)

* [ ]  rename broadcast_notification in service ([LSPS5 implementation #3662 (comment)](https://github.com/lightningdevkit/rust-lightning/pull/3662#discussion_r2218580234))

* [ ]  copy LSPSDateTime instead of cloning [LSPS5 implementation #3662 (comment)](https://github.com/lightningdevkit/rust-lightning/pull/3662#discussion_r2218590430)

* [ ]  docs wrong and return Duration instead of u64 on abs_diff [LSPS5 implementation #3662 (comment)](https://github.com/lightningdevkit/rust-lightning/pull/3662#discussion_r2218598607)

* [ ]  do not duplicate DEFAULT_RESPONSE_MAX_AGE_SECS [LSPS5 implementation #3662 (comment)](https://github.com/lightningdevkit/rust-lightning/pull/3662#discussion_r2218624527)

* [ ]  clean up the overall PeerState once it's empty [LSPS5 implementation #3662 (comment)](https://github.com/lightningdevkit/rust-lightning/pull/3662#discussion_r2218635296)

Yes, please open (a) tracking issue(s) for these, preferably with links to the original comment to establish context.

tnull

Alright, feel free to squash from my side, and then we should land this as-is, IMO, if that's alright with @TheBlueMatt

…5/service when signing notifications

Allows validating webhook URLs without depending on the external url crate.

Define LSPSMessage request, response and error types. Also introduce LSPS5AppName, LSPS5WebhookUrl, WebhookNotification types

Introduce SendWebhookNotification event for LSPS5/service, and also WebhookRegistered, WebhookRegistrationFailed, WebhooksListed, WebhookRemoved and WebhookRemovalFailed events for LSPS5/client.

Implements the LSPS5 webhook registration service that allows LSPs to notify clients of important events via webhooks. This service handles webhook registration, listing, removal, and notification delivery according to the LSPS5 specification.

Implements the client-side functionality for LSPS5 webhook registration, allowing clients to register, list, and remove webhooks with LSPs.

…ions from an LSP. As context, this utility started as part of the client, but was extracted in favor of having it separated, so it's clear that this functions should not be used by the client, but by the proxy server that has to forward the notifications

Fully integrates the LSPS5 webhook components into the lightning-liquidity framework, enabling usage through the LiquidityManager.

martinsaposnic · 2025-07-21T15:01:32Z

Fixups squashed!

issue with follow ups #3944

TheBlueMatt · 2025-07-22T00:27:11Z

lightning/src/sign/mod.rs

@@ -930,6 +930,14 @@ pub trait NodeSigner {
 	/// message to be broadcast, as otherwise it may prevent one from receiving funds over the
 	/// corresponding channel.
 	fn sign_gossip_message(&self, msg: UnsignedGossipMessage) -> Result<Signature, ()>;
+
+	/// Sign an arbitrary message with the node's secret key.


nit This makes it sound like the message should be signed directly, but in fact we should sign with the prefix "Lightning Signed Message:"

TheBlueMatt · 2025-07-22T00:33:16Z

lightning-background-processor/Cargo.toml

 std = ["lightning/std", "lightning-liquidity/std", "bitcoin-io/std", "bitcoin_hashes/std"]
+time = ["std", "lightning-liquidity/time"]


If we're gonna introduce a time feature in the BP crate we have to make sure we don't fetch time when its not set. That means disabling the threaded/std BP constructor too. I'm not really convinced having a separate feature here is worth it, then, because we enable the same set of things between std and time (there's only really two things in the whole crate - the async+no-std BP and the sync/threaded/std/time one).

martinsaposnic mentioned this pull request Mar 11, 2025

Add bLIP 55: Webhook Registration (LSPS5) lightning/blips#55

Open

ldk-reviews-bot requested a review from arik-so March 11, 2025 20:22

tnull self-requested a review March 11, 2025 20:37

wpaulino removed the request for review from arik-so March 11, 2025 20:39

tnull reviewed Mar 13, 2025

View reviewed changes

martinsaposnic force-pushed the lsps5 branch from 3aca4fc to 4dbe74d Compare March 14, 2025 14:48

martinsaposnic marked this pull request as draft March 14, 2025 14:49

martinsaposnic force-pushed the lsps5 branch 2 times, most recently from 1d4b47c to edf5346 Compare March 14, 2025 16:31

martinsaposnic marked this pull request as ready for review March 14, 2025 16:31

ldk-reviews-bot requested a review from valentinewallace March 14, 2025 16:32

martinsaposnic requested a review from tnull March 14, 2025 17:12

martinsaposnic force-pushed the lsps5 branch 7 times, most recently from 9809682 to af5929e Compare March 16, 2025 14:24

tnull removed the request for review from valentinewallace March 17, 2025 08:33

martinsaposnic force-pushed the lsps5 branch from af5929e to e018300 Compare March 17, 2025 16:10

martinsaposnic force-pushed the lsps5 branch 2 times, most recently from 2586494 to d0f64cc Compare July 19, 2025 19:37

martinsaposnic requested review from tnull and TheBlueMatt July 20, 2025 13:34

tnull reviewed Jul 21, 2025

View reviewed changes

martinsaposnic force-pushed the lsps5 branch from d0f64cc to 99a719e Compare July 21, 2025 13:20

martinsaposnic added 2 commits July 21, 2025 10:31

Introduce 'time' feature in lightning-liquidity.

91244a8

This will be used to allow disabling time-dependent functionality. 'time' is included in the features default.

Prefactor - Improvements on LSPSDateTime

f3811c2

Introduce new_from_duration_since_epoch constructor from Duration. Also add abs_diff function to use on client / service. Also do feature='time' instead of feature='std' on time related functionality

martinsaposnic force-pushed the lsps5 branch from 99a719e to 1dc1262 Compare July 21, 2025 13:54

martinsaposnic requested a review from tnull July 21, 2025 14:06

martinsaposnic force-pushed the lsps5 branch from 1dc1262 to 31c3a2f Compare July 21, 2025 14:42

tnull reviewed Jul 21, 2025

View reviewed changes

martinsaposnic added 10 commits July 21, 2025 11:50

Prefactor -> Introduce sign_message on NodeSigner, to be used by LSPS…

0137c7c

…5/service when signing notifications

Add custom URL parser for LSPS5.

17deae5

Allows validating webhook URLs without depending on the external url crate.

Add LSPS5 message formats for webhook registration

f0dff52

Define LSPSMessage request, response and error types. Also introduce LSPS5AppName, LSPS5WebhookUrl, WebhookNotification types

Add LSPS5 service and client events

bf90bfd

Introduce SendWebhookNotification event for LSPS5/service, and also WebhookRegistered, WebhookRegistrationFailed, WebhooksListed, WebhookRemoved and WebhookRemovalFailed events for LSPS5/client.

Add LSPS5 webhook service implementation

ee27d18

Implements the LSPS5 webhook registration service that allows LSPs to notify clients of important events via webhooks. This service handles webhook registration, listing, removal, and notification delivery according to the LSPS5 specification.

Add LSPS5 webhook client implementation

cbd3efa

Implements the client-side functionality for LSPS5 webhook registration, allowing clients to register, list, and remove webhooks with LSPs.

Add LSPS5 module structure

9c6ac71

Integrate LSPS5 with liquidity manager

233bad2

Fully integrates the LSPS5 webhook components into the lightning-liquidity framework, enabling usage through the LiquidityManager.

Add tests for LSPS5 client and service.

245c2c0

martinsaposnic force-pushed the lsps5 branch from 31c3a2f to 245c2c0 Compare July 21, 2025 14:55

martinsaposnic mentioned this pull request Jul 21, 2025

LSPS5 Follow ups #3944

Open

9 tasks

tnull approved these changes Jul 21, 2025

View reviewed changes

TheBlueMatt reviewed Jul 22, 2025

View reviewed changes

		std = ["lightning/std", "lightning-liquidity/std", "bitcoin-io/std", "bitcoin_hashes/std"]
		time = ["std", "lightning-liquidity/time"]

LSPS5 implementation #3662

Are you sure you want to change the base?

LSPS5 implementation #3662

Conversation

martinsaposnic commented Mar 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Mar 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

martinsaposnic commented Mar 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Mar 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

tnull left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ldk-reviews-bot commented Mar 13, 2025

Uh oh!

tnull commented Mar 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnull commented Mar 13, 2025

Uh oh!

martinsaposnic commented Mar 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Mar 17, 2025

Uh oh!

ldk-reviews-bot commented Mar 17, 2025

Uh oh!

martinsaposnic commented Jul 20, 2025

Uh oh!

tnull left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

martinsaposnic commented Jul 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnull commented Jul 21, 2025

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

martinsaposnic commented Jul 21, 2025

Uh oh!

TheBlueMatt Jul 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

martinsaposnic commented Mar 11, 2025 •

edited

Loading

ldk-reviews-bot commented Mar 11, 2025 •

edited

Loading

martinsaposnic commented Mar 11, 2025 •

edited

Loading

codecov bot commented Mar 11, 2025 •

edited

Loading

tnull left a comment •

edited

Loading

tnull commented Mar 13, 2025 •

edited

Loading

martinsaposnic commented Mar 14, 2025 •

edited

Loading

tnull left a comment •

edited

Loading

martinsaposnic commented Jul 21, 2025 •

edited

Loading

TheBlueMatt Jul 22, 2025 •

edited

Loading